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Abstract.  Software  Assurance  is  the  practice  of  designing  secure  software  that 
can  safely  and  reliably  operate  in  a  hostile  environment  and  resist  attacks  when 
all  other  network  defenses  have  failed.  Real-time  IA  focuses  on  mitigating  at¬ 
tacks  while  within  that  hostile  environment  but  can  be  greatly  aided  by  Software 
Assurance  practices  regardless  of  where  an  application  is  in  its  lifecycle.  In  2012, 
Yahoo  suffered  from  an  attack  on  an  application  initially  developed  by  another 
company  and  had  Yahoo  executed  Software  Assurance  techniques  on  the 
mature  application,  they  could  have  prevented  a  compromise  that  resulted  in  the 
release  of  more  than  400,000  user  names  and  passwords. 

Introduction 

In  May  of  2009,  President  Obama  said,  “Our  technological 
advantage  is  a  key  to  America’s  military  dominance.  In  today’s 
world,  acts  of  terror  could  come  not  only  from  a  few  extremists 
in  suicide  vests  but  from  a  few  key  strokes  on  the  computer— a 
weapon  of  mass  disruption!” 

So,  how  secure  is  your  application?  This  is  a  question  we  ask  each 
program  office  before  and  after  Software  Assurance  Risk  Assess¬ 
ments.  At  the  start,  programs  are  very  confident  with  the  security  of 
their  “baby”;  but,  once  we  finish,  that  confidence  is  usually  reduced.  As 
they  discover,  the  good  news  is  all  can  be  fixed;  and,  with  the  proper 
training,  tools,  techniques,  methods  and  processes,  they  can  ensure 
continuous  application  security  from  within  to  couple  with  the  real-time 
Information  Assurance  efforts  deployed  by  their  hosts. 

Software  Assurance  is  the  discipline  of  defensively  coding 
software  applications/systems  in  order  to  harden  them  from 
compromise/hacking.  While  traditional  software  engineering 
and  coding  practices  emphasize  user  functionality  and  follow- 
on  sustainability:  deferring  security  to  systems-level  design), 
Software  Assurance,  by  comparison,  bakes  security  into  the 
software  itself.  It  does  not  come  at  the  expense  of  user  func¬ 
tionality  or  follow-on  sustainability— it  adds  security  up-front,  in 
a  deliberate  effort  to  make  the  systems  as  least-hackable  as 
possible,  especially  those  operating  in  contested  environments. 

In  addition  to  being  a  sound  systems  engineering  practice, 
Software  Assurance  is  now  a  legislative  requirement.  More 
specifically,  Section  933  of  Public  Law  1  12-239  [1]  requires 
the  Office  of  the  Under  Secretary  of  Defense  for  Acquisition, 


Technology,  and  Logistics  and  DoD  Chief  Information  Office  to 
develop  and  implement  a  baseline  Software  Assurance  policy 
for  the  entire  lifecycle  of  systems. 

To  fully  comply  with  P.L  1  1 2-239  and  improve  Mission  Assur¬ 
ance  for  the  ever-increasing  majority  of  software-enabled  sys¬ 
tems,  enforcement  mechanisms  must  be  put  in  place  to  require 
assessments  prior  to  system  fielding  as  well  as  throughout  their 
lifecycle.  Current  policy,  guidance,  enforcement  mechanisms  and 
force  structures  are  inadequate  for  full  compliance. 

In  today’s  ever-changing  environments,  Software  Assurance  is 
Mission  Assurance!  Government  and  industry  leaders  in  the  soft¬ 
ware  security  community  have  advocated  for  years  for  widespread 
Software  Assurance  strategy  implementation.  They  have  struggled 
with  insufficient  official  guidance,  the  absence  of  dedicated  funding 
sources  and  lopsided  emphasis  on  hardware  and  network  security 
instead  of  software,  where  industry  analysts  believe  the  majority  of 
attacks  occur.  Acquiring  and  building  software  without  accounting 
for  security  is  no  longer  an  acceptable  risk. 

The  “way  ahead”  is  simple. .  .the  DoD  must  proactively  find, 
identify,  and  assess  weaknesses  that  may  be  in  software  de¬ 
veloped  and/or  used  by  the  warfighter  before,  during  and  after 
fielding.  By  building  security  in  early  and  often  throughout  the 
software’s  lifecycle,  we  tie  security  into  the  overall  quality  and 
functionality  of  systems,  which  not  only  prevents  malicious  enti¬ 
ties  from  hacking  our  systems  proactively,  but  saves  millions  of 
dollars  per  year  in  cost  avoidance  caused  by  flaws  in  the  code, 
work  stoppage  from  system  failure,  re-engineering,  patching  and 
re-fielding.  Software  Assurance  is  not  just  a  “Just-In-Time”  pro¬ 
cess  utilized  for  fielding  new  technologies  but  allows  us  to  apply 
techniques  to  identify  and  fix  problems  due  to  bloat,  years  of 
various  coding  techniques,  and  vulnerabilities  inherent  in  Legacy 
Software,  which  houses  the  vast  majority  of  our  critical  informa¬ 
tion;  thereby  hardening  the  current  infrastructure. 

Case  Study:  Yahoo  Voices 

In  July  of  2012,  a  hacking  group  posted  usernames  and 
passwords  that  had  been  pulled  from  a  Yahoo  sub-domain. 

The  group  itself  revealed  that  their  attack,  a  SQL  injection  that 
the  attackers  used  to  pass  information  retrieval  commands  to 
Yahoo’s  database  servers,  had  allowed  them  to  retrieve  almost 
half  a  million  unencrypted  email  addresses  and  passwords  [2]. 
As  the  details  of  the  attack  were  released  to  the  public,  Yahoo’s 
image  suffered  from  both  the  mistakes  that  allowed  the  attack 
to  happen  and  from  its  poor  damage  control  actions. 

The  problems  date  back  before  May  of  2010,  when  Yahoo 
purchased  Associated  Content  for  $100  million  to  rebrand  as 
its  Yahoo  Voices  service.  Associated  Content  provided  a  site  for 
writers  and  subject  matter  experts  to  have  an  official  platform  for 
their  articles  and  videos  [3].  Unfortunately,  Associated  Content 
had  not  built  their  platform  securely  and  Yahoo  had  not  fixed  any 
of  the  vulnerabilities  after  taking  control  of  the  application  [4]. 

Over  time,  Yahoo  moved  the  authentication  scheme  for  Yahoo 
Voices  over  to  its  own  logon  system  but  did  not  perform  many  secu¬ 
rity  fixes  beyond  that.  Unfortunately,  as  was  revealed  in  the  attack, 
they  did  not  remove  the  unencrypted  tables  nor  did  they  scan  for 
SQL  injections  in  the  application.  These  two  issues,  combined  with 
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Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 
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the  amount  of  time  the  vulnerabilities  were  exposed  to  the  Internet 
at  large  meant  that  the  attackers  were  able  to  discover  information 
about  the  databases  used  by  Yahoo  and  the  data  stored  within  [5]. 

Once  the  information  was  in  the  wild,  Yahoo  lost  the  op¬ 
portunity  to  become  the  primary  source  of  information  about 
the  attack.  It  was  unable  to  control  what  was  reported  and 
what  details  were  released  when  the  attackers  themselves  and 
security  experts  began  putting  the  pieces  together  and  reporting 
it  themselves.  The  statements  released  by  Yahoo  were  limited 
to  an  acknowledgement  of  the  posting  and  that  there  was  an 
investigation  and  fix  action  under  way  [6]. 

Real-Time  Information  Assurance 

Modern  network  defense  involves  reconfiguring  automated 
defenses  to  prevent  attacks  and  close  holes  uncovered  in  previous 
attacks.  Whenever  an  attack  occurs,  trained  incident  responders 
comb  the  logs  and  network  for  any  details  about  the  attack.  They 
identify  the  exploit,  possibly  gather  details  about  the  attacker,  and 
refine  the  network  devices  to  prevent  that  attack  from  happening 
again.  Whether  it  involves  updating  a  blacklist,  providing  recommen¬ 
dations  for  an  emergency  patch  or  evaluating  if  an  application  is  so 
insecure  that  a  portion  of  it  needs  to  be  disabled  or  hidden  to  protect 
the  network  as  a  whole,  all  of  these  techniques  are  used  reactively. 

In  order  to  protect  their  infrastructure  and  security  processes, 
Yahoo  released  only  the  details  that  were  required  by  law  and 
did  not  confirm  or  deny  any  additional  details  released  by  third 
parties.  Based  on  the  responses  and  news  releases  following 
the  attack,  we  cannot  say  whether  they  followed  industry  best 
practices  when  closing  security  holes  identified  in  this  attack, 
but  we  can  explain  those  best  practices  that  Yahoo  could  have 
followed  in  response  to  a  compromise  of  their  application. 

After  an  attack,  a  forensic  investigation  will  be  launched  with 
the  goals  of  gathering  as  much  information  about  the  attack 
to  secure  the  network  and  application  as  well  as  gathering 
information  about  the  attacker’s  origin  and  motives.  During  the 
preservation  and  acquisition  portions  of  the  response  network 
hardware,  servers,  and  other  items  which  contain  logs  or  infor¬ 
mation  about  the  attack  will  need  to  be  protected  from  further 
alteration.  This  may  include  disconnecting  network  systems 
causing  disruptions  and  outages  of  services.  If  all  systems  are 
left  connected  to  the  network  until  all  the  evidence  of  the  attack 
is  preserved,  the  network  operators  will  need  to  ensure  that  the 
live  environment  does  not  overwrite  or  alter  critical  information. 
Identifying  and  maintaining  data  sources  will  require  cooperation 
between  the  application  maintainer,  the  network  support  techni¬ 
cians,  and  any  other  experts  that  may  be  able  to  provide  inputs 
into  locations  of  potentially  relevant  data. 

From  the  logs  and  application  itself,  the  forensic  expert  or  persons 
responsible  will  have  to  compile  all  potentially  relevant  data  and  sift 
through  the  log  files  to  reconstruct  a  sequence  of  events.  There 
may  be  hundreds  of  thousands  or  millions  of  log  entries  captured 
as  part  of  the  data  collection  process  and  the  analyst  will  have  to 
identify  which  entries  are  normal  operations  and  which  entries  are 
potentially  relevant.  From  those  relevant  entries,  the  analyst  will  build 
a  timeline  of  events  in  order  to  determine  the  extent  and  execution  of 
the  attack.  The  sequence  of  events  will  also  point  to  the  weaknesses 


used  by  the  attacker  to  gain  access  to  the  compromised  system  and 
identify  any  other  compromised  systems  or  planted  malware. 

Once  the  results  of  the  forensic  investigation  are  complete, 
the  network  administrators  can  begin  to  patch  holes  at  the  net¬ 
work  layer  by  disabling  IP  addresses  at  the  firewalls  and  limiting 
traffic  to  the  impacted  system.  One  new  protective  measure 
that  has  seen  widespread  press  is  the  Web  Application  Firewall 
(WAF).  Just  as  a  firewall  sets  up  whitelists  and  blacklists  which 
allow  or  deny  blocks  of  IP  addresses  and  allowed  ports,  a  WAF 
is  a  device  that  learns  expected  HTTP  commands  and  blacklists 
HTTP  commands  that  may  contain  malicious  logic. 

It  is  possible  to  configure  a  WAF  by  hand  with  the  results  of 
a  forensic  investigation,  and  the  WAF  will  forever  prevent  that 
same  attack  from  occurring  again,  but  WAFs  share  the  same 
limitations  as  blacklists  in  that  unknown  vulnerabilities  cannot  be 
prevented.  To  address  this,  existing  vulnerability  scan  results  can 
be  converted  into  a  WAF  rule  set.  A  dynamic  vulnerability  scan 
can  test  every  field  in  an  application  for  susceptibility  to  known 
attacks  such  as  SQL  injection,  cross-site  scripting,  and  buffer 
overflows.  When  integrated  into  a  WAF,  the  results  can  then  pro¬ 
vide  a  basic  level  of  protection  against  known  types  of  attacks. 

If  a  dynamic  scan  is  not  run,  most  WAFs  have  a  learning  mode 
that  can  identify  expected  behavior  over  a  period  of  time.  Unfor¬ 
tunately,  a  deployed  application  may  undergo  constant  attacks 
and  certain  exploits  might  be  allowed  in  rules  created  during  that 
learning  period.  Once  the  rules  are  created,  they  will  be  monitored 
and  the  operator  can  view  any  requests  that  may  violate  them 
to  determine  if  a  rule  will  cause  issues.  All  of  the  rules  and  the 
results  of  their  monitoring  phase  will  need  to  be  evaluated. 

In  order  to  get  the  maximum  utility  out  of  a  WAF,  the  opera¬ 
tors  must  be  knowledgeable  in  several  areas  that  include  the 
specific  application  behavior  and  application  security  in  order  to 
ensure  that  rules  will  close  security  vulnerabilities  while  maintain¬ 
ing  functionality  of  the  application.  Just  as  network  firewall  rules 
implemented  to  improve  security  can  prevent  legitimate  traffic 
from  passing,  WAF  rules  can  disable  application  functionality  by 
preventing  legitimate  data  from  passing.  However,  sometimes 
functionality  may  need  to  be  disabled  in  the  name  of  security. 

Once  an  attacker  has  identified  a  critical  security  vulnerability 
that  can  bring  down  a  system  or  reveal  sensitive  information,  the 
assumption  is  that  they  and  other  attackers  will  use  that  vulner¬ 
ability  again.  Sometimes  the  hole  that  was  used  cannot  be  fixed 
without  rewriting  source  code  or  re-designing  the  application 
and  the  only  way  to  prevent  the  loss  of  further  data  is  to  disable 
the  vulnerable  functionality.  This  is  reserved  for  cases  where  a 
self  denial  of  service  is  preferable  to  further  compromise. 

Unfortunately  the  users  are  left  to  fill  the  gap  in  functionality 
with  workarounds  or  manual  processes  that  can  cost  an  orga¬ 
nization  more  man  hours  than  any  investigation  or  hotfix  action. 
After  taking  into  account  the  massive  costs  endured  by  an  or¬ 
ganization  following  a  successful  attack,  the  increased  develop¬ 
ment  costs,  schedule  time,  and  additional  coding  requirements 
of  a  rigorous  software  assurance  process  begins  to  make  sense 
for  both  software  developers  and  their  customers. 

In  Yahoo’s  case,  the  vulnerability  identified  in  their  investigation 
was  fixed  and  the  unencrypted  username  and  password  data- 
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base  was  removed.  However,  had  Yahoo  executed  a  Software 
Assurance  Assessment  prior  to  integration  of  the  Yahoo  Voices 
application  into  their  environment,  the  injection  vulnerability  and 
the  insecure  database  would  have  been  identified  before  it  was 
exploited.  By  not  proactively  eliminating  vulnerabilities,  Yahoo’s 
customers  and  public  image  suffered. 

Software  Assurance 

Real-time  information  assurance  tools  such  as  a  WAF  offer 
program  offices  a  measure  of  security.  They  provide  very  spe¬ 
cific  protections  to  an  application,  but  if  an  attack  is  not  defined 
by  their  threat  identification  systems  and  a  security  hole  still 
exists  within  the  source  code,  that  application  is  still  vulnerable. 
So  how  does  a  program  office  solve  this  problem?  The  integra¬ 
tion  of  a  Software  Assurance  policy  that  includes  both  dynamic 
and  static  analysis  of  the  application  source  code  is  essential  to 
preventing  exploitation  of  those  vulnerabilities  not  covered  by 
WAF  rules  and  filters. 

There  are  many  ways  Software  Assurance  can  be  integrated 
into  the  development  lifecycle  of  an  application,  but  they  all  come 
down  to  two  core  implementation  methods:  the  deep  dive  approach 
and  the  triage  approach.  Both  have  their  merits  and  drawbacks.  It 
is  up  to  program  managers  and  technical  leaders  to  discuss  both 
approaches  and  determine  which  is  best  for  a  given  application. 

The  Deep-Dive  Approach 

The  core  idea  behind  the  deep-dive  approach  is  to  identify 
as  many  security  issues  as  possible  through  a  combination  of 
static  and  dynamic  analysis  and  manual  penetration  testing. 
Every  method  of  every  class  in  every  file  must  be  scrutinized  and 
declared  vulnerability  free.  Even  the  system  architecture,  risk 
management  procedures,  and  systems  engineering  methodolo¬ 
gies  are  evaluated  for  security  vulnerabilities.  No  attack  surface 
is  left  unexamined.  As  a  result,  this  approach  is  often  quite  time 
consuming;  taking  anywhere  from  8  to  1 2  weeks  to  complete. 

A  deep-dive  is  often  conducted  toward  the  end  of  a  lifecycle 
when  active  development  has  finished,  but  before  QA  testing 
begins.  Once  done,  the  application  can  be  expected  to  pass 
rigorous  security  testing  and  is  ready  for  deployment.  This  ap¬ 
proach  works  best  when  used  with  large-platform,  MAC  I  -type 
systems  utilizing  more  classical  development  lifecycles  such  as 
the  Waterfall  lifecycle. 

Because  the  costs  in  both  true  dollar  amounts  and  man-hours 
can  be  extensive,  it  is  necessary  to  such  programs  to  plan  for  deep 
dive  approaches  in  the  planning  and  requirements  phases  of  their 
development  lifecycles.  Even  with  proper  planning,  the  costs  and  time 
needed  to  perform  a  deep  dive  security  analysis  makes  this  approach 
prohibitive  for  most  standard  applications  in  use  in  the  DoD  today. 

The  Triage  Approach 

In  today’s  fast-paced  development  environments  a  Software 
Assurance  approach  that  takes  weeks  to  complete  just  is  not 
feasible.  Program  offices  utilizing  RAD  or  Agile  development 
cycles  simply  cannot  allocate  more  than  a  week  to  Software  As¬ 
surance  practices.  In  such  cases,  a  triage  approach  may  be  best. 

Time  is  not  the  only  resource  saved  by  the  triage  approach 


to  Software  Assurance.  The  material  costs  are  also  dramatically 
lower.  Triage  is  an  overall  cheaper  alternative  to  the  deep  dive 
security  analysis  of  a  system.  As  a  result,  it  lends  itself  to  legacy 
systems  (those  systems  that  have  entered  into  the  maintenance 
and  sustainment  portions  of  their  lifecycles)  where  funding  for 
extensive  testing,  evaluation  and  repair  is  often  not  available. 

A  triage  approach  to  Software  Assurance  emphasizes  iden¬ 
tifying  and  remediating  low-hanging  fruit  through  static  and/or 
dynamic  analysis.  In  this  approach,  it  is  not  so  important  to  iden¬ 
tify  and  remediate  every  single  security  threat,  only  the  easiest 
or  those  deemed  to  be  the  highest  risk  should  be  considered. 

As  each  iteration  of  the  lifecycle  completes,  more  and  more  is¬ 
sues  will  be  identified  and  remediated. 

While  this  issue  takes  significantly  less  time  than  the  deep¬ 
dive  approach  to  Software  Assurance,  there  is  one  glaring  flaw: 
if  a  high-risk  security  issue  is  not  properly  identified,  the  ap¬ 
plication  could  remain  vulnerable  through  several  development 
iterations.  This  is  where  real-time  IA  measures,  like  WAFs,  can 
help  mitigate  the  risk  to  an  application. 

Consider  the  Yahoo  case  study  presented  earlier:  Associated 
Content  was  not  a  large  mega-corporation  capable  of  spending 
millions  of  dollars  to  implement  a  deep-dive  Software  Assur¬ 
ance  program.  At  the  time  of  their  acquisition  by  Yahoo  in  May 
of  2010,  the  triage  approach  to  Software  Assurance  was  still  in 
its  infancy,  but  it  could  have  saved  Yahoo  from  both  the  financial 
and  reputation  losses  it  undoubtedly  suffered. 

A  triage  of  the  Associated  Content  software  would  have  revealed 
the  SQL  Injection  vulnerability  that  allowed  attackers  to  retrieve  the 
unencrypted  passwords  and  e-mail  address  of  the  systems  users. 
Real-time  Information  Assurance  measures  could  have  been  put 
into  place  that  would  have  prevented  the  exploitation  while  Yahoo 
developers  took  a  closer,  more  analytical,  look  at  the  vulnerability  that 
would  have  revealed  the  lack  of  proper  encryption  of  the  data  stored 
in  the  legacy  database.  Unfortunately,  many  of  the  developers,  man¬ 
agers,  and  Information  Assurance  personnel  at  Yahoo  may  not  have 
known  that  a  Software  Assurance  plan  was  a  necessity  because 
they  lacked  the  proper  training  to  identify  such  risks. 

Education  is  Key 

Regardless  of  which  approach  is  used  to  identify,  catalog, 
and  remediate  security  vulnerabilities,  it  may  all  be  wasted  ef¬ 
fort  without  proper  education  and  training  of  program  person¬ 
nel.  While  security  is  becoming  a  hot  topic  to  teach  as  part  of 
a  software  and  computer  engineering  program,  the  majority 
of  programmers  have  not  yet  had  much  exposure  to  software 
security  and  secure  development  training.  Ideas  such  as  data 
validation  for  security  and  whitelists  are  foreign  concepts  to  a 
large  percentage  of  the  software  development  workforce.  As  a 
result,  it  becomes  necessary  to  ensure  that  everyone  involved  in 
the  development  lifecycle  receives  a  degree  of  training  concern¬ 
ing  Software  Assurance.  It  is  imperative  that  developers  and  tes¬ 
ters  understand  how  to  identify  security  risks  to  the  application 
and  how  to  remediate  those  risks. 

In  the  end,  it  is  equally  important  that  IA  personnel  and  pro¬ 
gram  management  learn  the  language  of  Software  Assurance 
so  they  can  communicate  openly  with  the  developers  and  tes- 
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ters  about  the  sort  of  risks  associated  with  dif¬ 
ferent  vulnerabilities.  This  can  only  be  achieved 
through  repeated  exposure  to  education  and 
training  materials,  and  an  open  dialog  about  the 
overall  security  profile  of  an  application. 

Combining  Software  Assurance  and  Real- 
Time  Information  Assurance  measures  helps 
to  ensure  that  security  gaps  in  an  application’s 
source  code  are  covered,  at  least  temporarily,  by 
the  rules  governing  the  WAF.  But,  once  a  WAF 
is  in  place,  why  bother  repairing  those  gaps?  As 
mentioned  earlier,  WAFs  and  other  Real-Time 
Information  Assurance  measures  essentially 
amount  to  security  blacklists:  defining  what 
harmful  information  should  look  like  and  block¬ 
ing  it  at  the  server  and/or  application  layers.  As 
attackers  refine  their  techniques  and  new,  more 
creative  methods  to  defeat  these  blacklists  are 
created,  the  rules  governing  what  tainted  or 
harmful  data  looks  like  will  need  to  change. 

If  security  flaws  are  not  fixed  at  the  source, 
engineers  will  find  themselves  in  an  arms  race 
trying  to  keep  Real-Time  Information  Assur¬ 
ance  rules  updated  to  defend  against  current 
attack  vectors.  Repairing  the  security  holes 
at  the  source,  when  done  correctly  using 
whitelists  and  proper  data  validation,  puts 
an  end  to  the  arms  race  by  eliminating  the 
security  threat.  But  may  all  be  for  naught  if  the 
developers,  testers,  program  management,  and 
Information  Assurance  staff  are  not  properly 
educated  regarding  Software  Assurance  and 
the  risk  that  not  integrating  such  principles  into 
the  development  lifecycle  can  bring. 

Software  Assurance  is  not  just  an  option  to 
secure  our  critical  software  applications,  it  is  an 
absolute  necessity.  The  DoD  must  be  proactive 
when  it  comes  to  identifying  and  assessing 
the  weaknesses  present  in  software  in  use  by 
the  warfighter  and  our  national  infrastructure. 
Building  Security  in  to  the  software  lifecycle 
is  critical  to  this  task,  especially  if  it  is  built  in 
early  and  often.  Doing  so  will  prevent  cyber 
attacks  to  critical  systems  and  save  millions  of 
dollars  each  year.  Not  just  a  solution  for  new 
software  being  developed,  triage  approaches 
to  Software  Assurance  allow  legacy  systems  to 
incorporate  these  techniques  into  their  sustain¬ 
ment  plans  improving  the  preparedness  of  the 
nation  as  a  whole  to  all  cyber  threats. 

Disclaimer:  The  views  expressed  in  this 
article  are  those  of  the  authors  and  do  not 
necessarily  reflect  the  official  policy  or  position 
of  the  US  Air  Force,  Department  of  Defense  or 
the  U.S.  Government.^ 
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